Митя .NET разработчик и проблема с backoffice

Митя

Зарисовочка вам из жизни.

На работе Митя отвечал за важный кусок бизнес-логики. Он исполнил его в самом лучшем виде, грамотно вплёл в него лучшие практики, покрыл unit-тестами и написал кучу комментариев. Этот замечательный, декомпозированный на слои и использующий асинхронный доступ к БД кусок системы был личной гордостью Мити. "Во всём должен быть порядок" — справедливо полагал Митя.

У продуктовой компании, где работал Митя было шикарное и красивое web-приложение для внешних пользователей. А ещё было старое и некрасивое приложение-backoffice. Ну знаете, админка без внешнего доступа где можно банить неугодных пользователей, загружать новый контент и смотреть статистику. Пользовались оным контент-менеджеры, модераторы и тётушки-бухгалтеры для построения квартальных отчётов.

Директор компании в своё время волевым решением сконцентрировал все силы, деньги и лучшие кадры на web-приложении для внешних пользователей. А разработку backoffice проаутсорсили в компанию из чуть менее благополучной страны, где за разработку взялись вчерашние студенты. Вышло криво и неудобно, зато быстро и без драмы в финансовых отчётах. Впрочем, то были дела давно минувших дней. Ныне код backoffice лежал в отдельном репозитории, менялся раз в год по праздникам и деплоился вручную. Всё плюс-минус работало и всех устраивало.

Однажды начальство поручило Мите задачу: в backoffice нужно интегрировать часть функциональности из той бизнес-логики за которую отвечает Митя. Мол, ты, Митя, в этом разбираешься — тебе и карты в руки. Митя взял под козырёк и перенёс тикет в In Progress. Чтобы не дублировать код, собрал свой любимый кусок бизнес-логики в NuGet-пакет и пошёл с ним в backoffice.

Пришёл Митя в backoffice, а там — старый ASP .NET MVC, который ещё до асинков появился. И тут Митю и накрыло экзистенциальным кризисом. Переделать бизнес-логику на синхронную нельзя. Во-первых, асинки — это бэст практис, во-вторых дублировать код плохо. Поставить на тасках .Wait() нельзя — задедлочится в виду особенностей ASP.NET-ной многопоточности. На предложение переписать backoffice под новую версию MVC начальство покрутило пальцем у виска.

Митя погоревал до весны, после чего уволился и уехал в деревню, разводить сусликов на мясо. И больше никогда не приближался к программированию. Так-то.

Чему нас учит эта история?

Во-первых, бедный Митя в виду молодости не знал о таком понятии как трейд-офф. Суть трейд-оффов состоит в том, что иногда нужно отказаться от одних важных и нужных вещей, чтобы получить другие. В шахматах это называется гамбит.

Во-вторых, Митя, очевидно, слишком серьёзно воспринимал бэст практики. Предписания — это, конечно, удобно. Но в нашей работе, знаете, готовых рецептов мало. Чтобы быть хорошим разработчиком — увы, мало знать лучшие практики. Надо понимать как они работают, а главное — что они вам дадут конкретно в вашей ситуации. И что отнимут. Бэст-практики сделали Митю похожим на обезьяну, засунувшую лапу в дупло, в которое охотник положил банан. Лапа застряла, а отпустить банан противоречит системе ценностей обезьяны.

В-третьих, наша профессия не изотропна.

Последовательность хороших и правильных "в моменте" решений далеко не всегда ведёт к хорошему и правильному результату. И ничего с этим не поделать.

Такие дела